Method and system for transferring information between multiple buyers and multiple sellers

ABSTRACT

A method for transferring information between multiple buyers and multiple vendors is provided. Information is received from a plurality of sources. This information corresponds to a plurality of products. This information is stored in a first database. A request is received. The request concerns a portion of the information stored in the first database. The request is then retrieved from the first database and posted to a second database. Access is provided to subsets of the second database to a plurality of subscribers.

APPLICATION HISTORY

[0001] This Application claims the benefit of U.S. Provisional PatentApplication, Serial No. 60/262,182, filed on 17 Jan. 2001 and entitled“Method and System for Transferring Blood-Related Information BetweenMultiple Buyers and Multiple Sellers of Blood,” and U.S. ProvisionalPatent Application, Serial No. 60/262,184, filed on 17 Jan. 2001 andentitled “Method and System for Transferring Inventory InformationBetween Multiple Buyers and Multiple Sellers.”

FIELD OF THE INVENTION

[0002] The present invention generally relates to the field ofinformation transfer and, more specifically, to a method and system fortransferring information between multiple buyers and multiple vendors.

BACKGROUND OF INVENTION

[0003] Traditional inventory management systems were internally focused(i.e., only concerned about a particular customer or a particularvendor), and insight into inventory on hand was limited to each party'sown staff. As a result, inventory management systems for both customersand vendors were limited to managing current stock on hand and alertingresponsible parties when to re-order certain products. Any visibilityinto a customer's inventory level by a vendor or a vendor's stockinglevel by a customer was established through a specific arrangement andproprietary computer system integration.

[0004] Another obstacle was that, in most vendors' and most customers'internal systems, inventory, production, sales management, billing, etc.were very often based on many separate computer systems. These systemslacked the standardization afforded by a common communicative language,one that would enable an efficient data exchange. Furthermore, this lackof standardization prevented not only vendors from proactively managingtheir customers, but also prevented different departments of the samecustomer from accurately viewing product stocking and consumption rates.

[0005] There is, therefore, a need to provide a method and system fortransferring information between multiple buyers and multiple sellersthat overcomes the above-stated disadvantages.

SUMMARY OF THE INVENTION

[0006] The present invention provides an industry-wide, multi-partyinventory management system. The system of the present inventioncomprises a collective view of the inventory levels within an entiremarket while extending the “just in time” inventory practices of eachmanufacturer to the point of consumption through the deployment of“point of use” level data capture devices and a central database.Individually established product re-supply level points are used by thecentral database's operating system to trigger a vendor's re-supply andbilling mechanisms. Licensed access by a manufacturer sales or servicerepresentative in the field, coupled with the use of similar datacollection devices, enables the management of truck stock inventory andthe corresponding product visibility with regard to location, type anddisposition. Furthermore, the optimization of the product at the pointof use is made possible by licensed access for a vendor and theirability to use the present invention and supporting decision tools tomove the necessary inventory to the optimal or immediate point ofconsumption. Since the needs of each customer is different, the presentinvention allows individual vendor and customer licensors to setmutually agreed-upon inventory levels which satisfy the operationalrequirement for each customer, while avoiding excessive stocking byeither party.

[0007] The present invention is thus designed to invigorate and optimizethe general commercial activities of participating industries. Beyondsimple inventory consumption triggers and product level analysis, thepresent invention provides a platform for the easy collection anddissemination of a wide range of commerce-related information throughoutan industry, without burdening any party with more than a single, directinterface to all other parties. Furthermore, intelligent controls limitaccess by each individual while mutually agreeable licensing agreementsand syndicate arrangements allow each vendor and customer to control theexpansion and participation of parties in the model.

BRIEF DESCRIPTION OF THE FIGURES

[0008]FIG. 1 is a schematic diagram of the current environment of aninventory management system;

[0009]FIG. 2 is a schematic diagram of one embodiment of an inventorymanagement system, in accordance with the present invention;

[0010]FIG. 3 is a flow chart illustrating the basic function of thesystem of FIG. 2;

[0011]FIG. 4 is a flow chart illustrating the security and accesscontrol component of the system of FIG. 2;

[0012]FIG. 5 illustrates an array highlighting a dynamic creation ofcustomized data sets, according to the system of FIG. 2;

[0013]FIG. 6 illustrates an example of a two-dimensional data table, asused in the system of FIG. 2;

[0014]FIG. 7 illustrates an example of a vertical and hierarchical datatrees, as used in the system of FIG. 2;

[0015]FIG. 8 is a table illustrating user-determined thresholds, for usein the system of FIG. 2; and

[0016]FIG. 9 is a flowchart illustrating a method for transferringinformation between multiple buyers and multiple vendors, in accordancewith the system of FIG. 2.

DETAILED DESCRIPTION OF THE PRESENTLY PREFERRED EMBODIMENTS

[0017] The present invention relates to a community- or market-wide,multi-contributor, pooled inventory system that enables all licensedparties to have selective access to data elements. The data elementspreferably relate to various aspects of a particular industry. In turn,access to the data elements enable the licensed parties to effectspecific actions concerning the data elements, such as, for example,automated re-supply, billing, consignment, truck stock management,service, marketing, general communication improvements, etc. The presentinvention may be managed by one of the market participants or,alternatively, by an independent third party.

[0018] Shared visibility into product parameters—such as quantities,locations, expiration dates, arrival dates, delivery status, point oforigin, etc.—between multiple buyers on one hand and multiple sellers onthe other relies on a coordinated and common system between the parties.“Coordinated” in the above phrase means built and maintained to serveparticular subsets of relevant data to the respective parties, withfeatures that both add value on either end of the equation (distinctlyfor buyers and sellers) and provide protection for the parties' internaldata. The coordination of data gathering, storage, sharing, andvalue-added manipulation between multiple independent buyers andsuppliers (or distributing and receiving entities in the case of asingle organization) is the essence of this invention. The preferredembodiment of a coordinator in this invention is the host and ongoingadministrator of an electronic repository of data and software toolsthat together constitute a software application, also known as anapplication service provider (ASP). “Common,” as used above, meansavailable to both the parties, as part of their current (or an easilyobtainable) internal system for transmitting, manipulating and viewinginformation, and based on communication standards supported on both endsof the transaction. The preferred embodiment of a common system forcommunication is, in this case, the Internet or any similarcommunication system.

[0019] The processes covered by this invention may be grouped intogeneric features (such as security) and two independent cycles (forbuyers and sellers), with several points of intersection. Elements ofthese cycles—selected features that add value for users of the system byenhancing insight into inventory disposition and related commercialactivity—are not new. The invention's innovations lie in the particularprocesses that make the data valid, comprehensible and useful to partieson opposite ends of a transaction and in the cumulativeeffect—real-time, shared visibility into inventory at the point of useor sale, forming an industry-wide, multi-party inventory managementsystem.

[0020] By enabling the multi-customer collection and pooling ofinventory, the present invention permits an entire vertical market ofcustomers having similar interests to take advantage of higher levels ofservice from an unlimited number of vendors and distributors, includingwidespread consignment inventory practices.

[0021] Furthermore, by pooling data contributions from multiplecustomers and by allowing vendors to view and interpret specific data asit relates to certain rules of access, the present invention foregoesthe need for each individual customer to have a computer connection toeach vendor or distributor. Thus, from either the vendor or distributorperspective, the multi-customer pooled data provides insight and enablesaction with regard to individual customers, but also foregoes thetraditional requirement of having a specific link or intermittent queryof each individual customer.

[0022] Furthermore, the present invention enables an extension of “justin time” manufacturing practices through to the point of consumption.This increased visibility on product stocking levels enables theparticipating manufactures to optimize available product across theentire market, to view field agent's trunk supply, to move productthroughout the market in order to minimize excess manufacturing, toreview consumption of critical supply and to manage customer consignmentprograms.

[0023] To this end, a “many to many” method and apparatus for thesyndication of inventory and associated data between two or more partiesvia a computer system or systems managed by one of the parties or by athird, independent party through an “all parties” licensing arrangementis provided by the present invention. According to the presentinvention, competitive manufacturers or suppliers of product obtainlicensed access to a database which contains continuously updatedcondition and consumption information on their products provided by themarket consumers via barcode readers or like systems. Additionally, thecentral database managing licensor accepts inventory data from licenseesand then assembles, sorts and feeds back a collection of the relevantdata to all engaged parties in the arrangement to include productmanufactures and their agents, as well as producers, distributors,testers and consumers or users.

[0024] Data contribution can also include information from themanufacturer or distributor to the customer on the status of productwhich is in route to the customer's location, as well as information onpricing, billing, account status, product recalls, marketing and thelike. Although commerce can be executed through the system, the presentinvention is primarily designed to collect and organize data whichoptimizes the entire commercial process, but is not limited to oneelement, such as, for example, the product selection or purchase.

[0025] To that end, licensing parties might also include other commercefacilitators such as group purchasing organizations and industry-widecommunication exchanges (e.g., Internet exchanges). These organizationsmay license information regarding the continuous flow of product betweenthe customers and the vendors or distributors in order to enable suchactivities as charge-back programs, volume discounting, contractcompliance analysis and the like.

[0026] The “many to many” inventory data syndication model, aspromulgated by the present invention, is primarily designed to enablemultiple common customers of the same groups of vendors or distributorsto avoid the requirement of multiple unit of use collection systems andmultiple interfaces to vendor order fulfillment systems. Likewise, froma vendor's or distributor's perspective, the present invention limitsthe required number of customer interfaces from one for each customer toone for the entire engaged market. As a result, the present inventionpertains to a wide variety of markets. However, it is of particularbenefit in markets where full integration and use of standardizedproduct coding and or communication languages is lacking. This absenceof standardization may be due to a dearth of industry focus, competitivepositions of suppliers or a lack of available technology skills at thecustomer end. Furthermore, the present invention applies particularlywell in markets where the material being produced, sold, distributed,controlled, managed, tracked and/or consumed is subject to one or moreof the following characteristics:

[0027] The items are labile in nature or subject to obsolescence;

[0028] The items can be labeled with incremental information regardingnewly revealed characteristics while awaiting consumption, thusessentially changing their identity;

[0029] The items can be moved between various points of use in order toavoid spoilage and to optimize supply;

[0030] The items can be part of a consignment inventory arrangement; and

[0031] The items may be managed by a central database-type system ofsyndicated information which is then provided to various contributingand consuming parties via a licensing relationship.

[0032]FIG. 1 illustrates a schematic diagram of the current environmentof an inventory management system 10. For purposes of the example shownin FIG. 1, it will be assumed that the industry in question concerns thesupply and distribution of implanted medical devices. Alternatively, theinventory management system described here may be applicable to otherproducts. Such products include, for example, blood and blood-relatedcomponents (i.e., plasma, retics, red blood cells, white blood cells,etc.), body organs for transplant (i.e., eyes, kidneys, skin, livers,lungs, hearts, etc.), bone marrow and related components, geneticmaterial (i.e., cells, DNA, RNA, eggs, semen, etc.), limbs, (i.e.,fingers, hands, toes, legs, arms, ears, etc.), hair and follicles,implanted and external bodily function support or monitoring devices(i.e., pumps, pacemakers, prosthetics, ocular devices, stents, etc.) andorganic compounds (i.e., cloned organisms, cells, organs, animals,etc.). The inventory management system may also include veterinary(i.e., non-human) applications for all the medical items listed above.Additionally, the inventory management system may be directed tonon-medical labile or “time-sensitive” products, such as cattle,poultry, raw meat and seafood, prepared meat and seafood, wild animals,dairy products, other non-meat prepared foods, plants, flowers, grain,seeds, water, ice, wine, beer, liquor, lumber, apparel and footwear,home furnishings, seasonal goods, toys, reading materials, computers andelectronics, packaged software, appliances, hardware, home improvementsupplies, industrial supplies, gases, organic fuels and lubricants(i.e., oil gasoline, etc.) and genetically-altered components.

[0033] Referring to FIG. 1, users of implantable medical devices 12,14,16, 18, mainly hospitals, order supplies from a plurality of suppliers20, 22, 24, 26. The suppliers 20, 22, 24,26 may sometimes be undercontract with the users 12, 14, 16,18. Generally, the users 12,14,16,18will additionally have a storage area 28,30, 32, 34. The storage areas28, 30, 32, 34 preferably store, inventory and match the products topatients. The storage areas 28, 30, 32, 34 may be an internal departmentwithin a particular user, as shown; may be shared between two users (asillustrated by reference numeral 36); or outsourced to a third party (asillustrated by reference numeral 38).

[0034] The third party storage area 38 may even be an independentproduct supplier offering an additional service. In such a case, thethird party supplier 38 may employ agents (as shown by the linereferenced by numeral 40) to deliver the product to the user 18 whenordered. In all cases, however, the user's staff communicates frequently(as shown by the line referenced by numeral 42) with the supplier 24regarding the inventory needed at the user's facility. As required,agents 44 may be dispatched to move products to users (as shown by theline referenced by numeral 46) or between users (as shown by the linereferenced by numeral 48) to address a need or to optimize thelate-dated supply of a certain product.

[0035] In all cases, communication on a continuous basis does not existbetween blood suppliers 20, 22, 24, 26 in the users 12, 14, 16, 18 orthe blood suppliers 20, 22, 24, 26 concerning the level, type,availability, dating, disposition and other pertinent details of theproduct.

[0036] At all relevant points within system 10, some portion ofinformation regarding the availability, status, disposition, dating andother pertinent details on the blood supply may be available. However,no system links these disparate points of information in an organized,reliable and accessible manner. As a result, significant energy,resources, time and supplies are wasted in the current model.

[0037]FIG. 2 illustrates a schematic diagram of one embodiment of aninventory management system 100 of the present invention. For purposesof the example shown in FIG. 2, it will be assumed that the industry inquestion concerns the supply and distribution of implantable medicaldevices. Alternatively, the inventory management system described heremay be applicable to other products. Such products include, for example,blood and blood-related components (i.e., plasma, retics, red bloodcells, white blood cells, etc.), body organs for transplant (i.e., eyes,kidneys, skin, livers, lungs, hearts, etc.), bone marrow and relatedcomponents, genetic material (i.e., cells, DNA, RNA, eggs, semen, etc.),limbs, (i.e., fingers, hands, toes, legs, arms, ears, etc.), hair andfollicles, implanted and external bodily function support or monitoringdevices (i.e., pumps, pacemakers, prosthetics, ocular devices, stents,etc.) and organic compounds (i.e., cloned organisms, cells, organs,animals, etc.). The inventory management system may also includeveterinary (i.e., non-human) applications for all the medical itemslisted above. Additionally, the inventory management system may bedirected to non-medical labile or “time-sensitive” products, such ascattle, poultry, raw meat and seafood, prepared meat and seafood, wildanimals, dairy products, other non-meat prepared foods, plants, flowers,grain, seeds, water, ice, wine, beer, liquor, lumber, apparel andfootwear, home furnishings, seasonal goods, toys, reading materials,computers and electronics, packaged software, appliances, hardware, homeimprovement supplies, industrial supplies, gases, organic fuels andlubricants (i.e., oil gasoline, etc.) and genetically-alteredcomponents.

[0038] The inventory management system 100 may preferably include acomputer algorithm program and software, which may be stored integralwith, or remote from, a central database 102. The computer algorithmprogram may preferably comprise any program capable of being stored onan electronic medium, such as, for example, RAM or ROM, and permitted tobe accessed (and consequently run) by microprocessor (not shown),preferably running integral with, or remote from, the central database102. Alternatively, the software running inventory management system 100may be performed manually by a programmer, electronically programminginstructions to the inventory management system 100, either remotelyfrom a location away from the inventory management system 100, or via anelectronic connection with the inventory management system 100.

[0039] Referring to FIG. 2, the embodiment of the inventory managementsystem 100 of the present invention comprises a model and apparatus forthe inventory management and distribution of implantable medicaldevices. In the embodiment shown, key information, such as the status,disposition, availability, price, age, etc. is contained in a single,multi-user, independent location, such as a database 102. Furthermore,the database 102 may be accessed by all parties appropriately involvedin the transaction of each unit of product.

[0040] Referring to FIG. 2, the fundamental change from the presentmarket picture (i.e., FIG. 1) is the addition of the independentlymaintained database 102. As seen in FIG. 1, the present market pictureis a competitive model that does not afford ease of communicationbetween market suppliers or customers concerning the status of theproduct. This creates waste and excessive effort to communicateeffectively regarding the supply.

[0041] By contrast, referring to FIG. 2, the present invention providesa central point of information 102, accessible by all (subject tocertain rules), without disturbing the existing market structure. Thereare still suppliers 104, 106 who compete for users 108,110. Product isstill brought to the user's facilities 112, 114 by shippers 116,118.Suppliers 104,106 still manufacturer products and hold it in theirwarehouse locations 122, 124 awaiting approval to distribute. Somesuppliers 104, 106 may choose to place part of their supply at thehospital on consignment 126, which is enabled and easily managed throughthe present invention.

[0042] Another element of the model is the proliferation of data accessand/or viewing devices 142, 144, 146, 148, 150, 152 that enable allparties to see their data on their supply. These devices can be asvaried as phones, pages, PDAs, computers, Internet browsers, etc. Thesedevices communicate with the central independent repository 102 viacommunication links 164, 166, 168, 170, 172, 174—importantly, withoutneed for a specific and proprietary communications protocol; rather,they rely on the standard communications protocol used to connect withthis common communications platform (a preferred embodiment is theInternet). Another change to the market model is the addition ofinformation collection devices (e.g., bar-code scanners) 128, 130, 132,134, 136, 138, 140, which are interfaced to a network which is in turnconnected to the database via the Internet or other network (e.g.,wireless). As indicated in FIG. 2, these devices 128, 130, 132, 134,136, 138, 140 are widely deployed throughout the invention to collectdata on a continuous basis.

[0043] The use of various data collection devices 128, 130, 132, 134,136, 138, 140 and data viewing devices 142, 144, 146, 148, 150, 152 byall significant players in the supply chain enables the constantupdating of the central independent repository 102. This system providescritical, and previously unavailable, information to the individuals,who can use the data in a proactive manner to optimize the blood supply.

[0044] Although traditional service contracts between suppliers andcustomers continue to exist in the current invention, the inventionenables new parties 154, e.g., industry analysts, to easily gain aconsolidated view of the product status, availability and disposition.In addition, the model allows rules of access to govern the availabilityof information between market players (i.e. between neighboringhospitals) so that they can support one another's needs. Likewise, therules of access can permit two affiliated suppliers to view each other'ssupply status while maintaining as proprietary the sources of thatsupply 120. Finally, although the various suppliers remain independent,the access rules that are a part of the invention can permit all partiesto optimize the supply that is in the channel. For example, theinvention enables all supplier representatives 116, 118 to use theirdata retrieval systems 136, 138 to move supply between hospitals (asreferenced by lines 156, 158, 160), while appropriately trackingownership for payment purposes.

[0045] In operation, this invention eliminates the product waste andexcessive and laborious communication and product shuffling effortassociated with the current market model.

[0046]FIG. 3 illustrates the basic function of the present invention. Adata collection device 128, 130, 132, 136, 138, 140 acquires informationin the form of a code (an example is the alphanumeric code indicated bya barcode). The code is communicated via computer link 182 to a centralProduct Information Database 200, which associates product attributeswith the alphanumeric code. The Product Information Database 200 isupdated by periodic communication via computer link 186 with a pluralityof Vendor Product Attributes Databases 204, maintained separate from theProduct Information Database 200 by a plurality of vendors or suppliers.When the Product Information Database 200 can't identify a code, itcommunicates the problem to the Exception Capture and Reporting Engine202 to be addressed and corrected. The Product Information Database 200continuously communicates via computer link 190 with a Central InventoryData Repository 104. The difference between the two databases is thatthe Product Information Database 200 is a record of single-instanceproduct information regarding a plurality of products, and is notmodified by exchanges with the Data Collection Device 128, 130, 132,136, 138, 140.

[0047] The Central Inventory Data Repository 104, on the other hand,maintains a dynamic record of multiple instances of a single productinformation code, in order to track product totals.

[0048] When a Communications Interface for Formatting and Viewing Data142, 144, 146, 148, 150, 152 (one embodiment is an Internet browser)requests a data subset, the request goes via computer link 180 to a DataSubset Presentation Engine 206. According to pre-selected parameters,the Data Subset Presentation Engine 206 acquires data via acommunications interface 188 from the Central Inventory Data Repository104, and presents the data subset via a communications interface 180through a Communications Interface for Formatting and Viewing Data 142,144, 146, 148, 150, 152.

[0049] Referring to FIG. 9, a method for transferring informationbetween multiple buyers and multiple vendors is illustrated. In Block500, a central node receives various information corresponding to aplurality of products. This information is preferably transmitted to thenode electronically, but may be by any other suitable means providingfor the transfer of information. Additionally, the information ispreferably sent to the node from a plurality of independent sources.Preferably, these independent sources are suppliers of a particularproduct (i.e., vendors). For example, a vendor may supply information tothe node regarding specific details about the product controlled byvendor, such as, for example, amount of product, size of product, costof product, etc.

[0050] Upon receiving the information, in Block 510, the node thenstores this information in a first database.

[0051] In Block 520, the node then receives a request for information.Preferably, this request may come form at least one user (or, morespecifically, would-be-user) of the product stored in the firstdatabase. For example, a buyer may inquire to the node as to the statusof a particular product.

[0052] In Blocks 530 and 540, the node retrieves the requestedinformation from the first database and posts the information to asecond database.

[0053] In Block 550, the node provides access to the second database toa plurality of subscribers. That is, according to a particularsubscriber's account, the node allows access to the second database.This method of selective allowance to the database is preferably basedon a number of security measures that allow restricted access to certaindatabases of information. Additional measures include, for example,login names and/or passwords. Thus, if a subscriber is allowed to accessa particular database for information relating to a particular product,that subscriber (whether a vendor or a buyer) may be permitted to viewthe information contained in the second database. In most cases, thesubscriber may be the same person or entity as the person or entitymaking the request for information in Block 520. However, such is not arequirement, and a subscriber may be different from the requestor.Assuming the subscriber meets the security requirements, the subscriberis permitted access to the second database.

[0054] Upon accessing the second database, the subscriber may transactbusiness with a particular vendor or buyer dealing in the product thatis the subject of the information contained on the second database. Thisis shown in Block 560.

[0055] What follows is a detailed description of the software componentsand processes of the system of the present invention. The term “page” asused in the following detailed system description refers to a discreteinterface for information presentation or interaction. A single processinvolving multiple steps may encompass many pages, but not every steprequires that a separate page be presented to the user (many steps arecarried out internally, without presentation or interaction with theuser).

[0056] Open Network Model. This invention relies on the participatingentities having a common platform of communication (the preferredembodiment for this invention is the Internet).

[0057] Security and Access Control. The invention's implementation ofdata security and user identification is critical to assembling andproviding access to specific data subsets, based on each usersrelationship to the community or market employing the system. Thissystem component is illustrated in FIG. 4.

[0058] 1. Log In

[0059] 1.1. Username and password protection. A coordinator or “host”creates and maintains a data record (preferred embodiment: an electronicdatabase accessible over the Internet) of valid user identificationcodes (usernames) and user passwords. Unique user passwords, encryptedin the system so that they are unknown even to the host, are critical tothis invention, in that they provide the means of delineating relevanttools and bodies of data to be presented to the user, in exclusion ofother tools and data that the user is not authorized to access.

[0060] 1.2. Forced Password Change 340 on first log in. Users arerequired to create a new password, unlike the current one, any time theylog in for the first time with a new or system-issued replacementpassword. This prevents access by anyone who discovers a user's initialpassword issued by the system (for example, via e-mail). The inventionuses a database “flag” to determine whether the user has every logged inbefore and resets this flag whenever a new password is created for theuser.

[0061] 1.3. “Module”-level security checking. Modules are discretefeatures or portions of features deemed sufficiently distinct to warrantindependent security protection. A user's access to each module isdenied by default unless specifically permitted by the coordinator.Users themselves may select and modify their own roles but may not alterthe relationship between any role and any module; this privilege isreserved for the coordinator.

[0062] 1.4. Roles and permissions. Users' roles define their generalfunction, position or “need to know” for purposes of the invention.Roles correspond to the aforementioned security keys, in that theydetermine which users have access to which modules (system features).Permissions govern which roles have access to which modules. Each userhas one or more roles. Each module is accessible by those users whoseroles have the appropriate permission.

[0063] 1.5. User identity and security keys 310. Multiple elements ofuser's online identity are communicated constantly throughout a user'sinteraction with the software, determining Application Module Access320, Data Subset Access 322, and rights for Communication With OtherSystem Users 324. While a user is in communication with the invention,all user activity is governed by the user's identity and the user's“security key.” The system obtains these elements from the Database ofUser Identities and Security Keys 330 in connection with the usernameand password. Once the user's username and password are validatedagainst the database and the corresponding security key and useridentity are obtained, a “session” with the system may proceed. Theuser's security key is a general identification grouping that determineswhether the user has access to a feature, function, area or page withinthe application (see Roles and Permissions under Section 2.2). Theuser's identity is unique to the user but also includes parameters thisuser shares with others in the same organization (i.e., the identity ofJane Smith, employee of SupplierA Inc., includes elements that identifyher uniquely as Jane Smith and generally as an employee of SupplierAInc.). This provides unique access to data sets such as her passwordchange input section and shared access to the specific data set thatthis invention reserves for ABC Inc. The combination of security key anduser identity determines what the user can access, view, and manipulatewithin this system. A sample of code for determining and acting on auser's identity and security keys upon arrival at a new page (oneembodiment is Active Server Pages, or ASP language, employed largely inthe development of Internet-based applications) is as follows: if notIsUserAllowed(“ModuleName”, ALLOW_VIEW) then   response.Redirect“not_allowed.asp”   response.End end if

[0064] In other words, if the role to which a user has been assigneddoes not having “viewing” permission to a module called ModuleName, thenthat user is redirected away from the page or feature of the system towhich he or she was seeking access.

[0065] Passing of this data to the system is at no time visible to oraffected by the user it occurs by virtue of a repeated verification ofuser identity and security key as stored, temporarily, on the user's owncommunication device. The preferred embodiment of the present inventionis an encrypted token or cookie, placed on the user's device by thesystem, and being automatically deleted upon manual or automatictermination of the user's session (see Section 2). Direct access to ormanipulation of either the security keys or identities by users is notpermitted.

[0066] A further example is the dynamic, on-the-fly creation ofcustomized data sets according to certain parameters of users'identities. The preferred embodiment of the present invention uses aMicrosoft SQL database. So, for example, a user may be identified partlyas having employerID=SupplierA. Because the user's identity travels withthe user throughout a session, available to every new page visited orfunction executed by the Data Subset Presentation Engine 206, specific,personalized data subsets can be called from the Central Inventory DataRepository 104 simply by using this and other values as constraints onthe user's request. This principle is illustrated in FIG. 5. Forexample, the following selects from a table inventory the current arrayof products 612 associated with a user whose employerID=SupplierA,excluding products from SupplierB 614 and SupplierC 616 stored in thesame Central Inventory Data Repository 104 where employerID<>(not equalto) SupplierA 610: SELECT   product_code, product_name, expiration_date,quantity FROM   inventory WHERE   employerID = 2

[0067] This is a traditional and common way of deriving subsets of datafrom a database, limiting access to data to those whose identity permitsit. The present invention's innovation is to provide the coordination ofthese security checks and resulting data sets between multiple buyersand multiple sellers.

[0068] 2. Log Out

[0069] 2.1. Manual. The preferred implementation under this inventionalso includes a visible control (screen button) and supporting code forterminating a user's session with the system. Once terminated andinactive, the connection cannot be used by any user to access ormanipulate the system or data it contains. Because of the aforementionedconstant communication of user identity and security key to the system,no module or component the system or its associated data may be accessedor manipulated outside an active session.

[0070] 2.2. Automatic based on a time interval. Along with the user'sidentity and security key, the system in this invention places a timestamp in the token or cookie on the users communication device. Witheach new transmission of a request to the system, it compares the timevalue to the central system's time value. If the time stamp on theuser's device is less than the time value on the central system by a setinterval, then the user is presumed to have been inactive since thattime and is logged off automatically.

[0071] 3. Coordinated Security of User Identities and Data.

[0072] 3.1. Access to user identities and data. The coordinator or hostcontrols access to user identities and related data. Users canmanipulate selected data points within their own and affiliated recordsin the database (e.g., employees at the same company or department), butthey cannot alter the composition or permissions associated with variousroles or security keys, and they cannot associate any user with anyentity or organization outside their own. (For example, a user from onecompany cannot be associated with any other company not under control ofor related to the first; a user within one division of any organizationcannot be associated with any other division, except by thoseuser-administrators with control over both divisions' associations.)Only the coordinator of the system has access to and control over users'affiliation in the system database with unassociated organizations.

[0073] 3.2. The preferred embodiment of this subsystem of useridentities and data is a hosted computer-network server, in a secureenvironment managed either by the main coordinating party or a separatethird-party.

[0074] 4. Communication Among Parties.

[0075] 4.1. Messages to trading partner. Preferred embodiment is e-mailmessage either within the system or from the system to any independente-mail system (such as Microsoft Outlook), and other embodiments includefax communication transmitted from the system to any outside faxinterface, paging systems, mobile phones, and other wirelesscommunications interfaces. The ability to use the system'scommunications tool and to reach specific other users of the systemdepends on a user's identity and security keys.

[0076] Buyer's Product Management Cycle: Receive, Monitor, RecordUse/Sale, Order. Once granted access, the buyer works with the system ina cycle of receiving goods, monitoring, recording use or sale of items,and ordering new items.

[0077] 1. Receive

[0078] 1.1. Add. The system maintains a running total of buyer'sinventory by incrementing current totals with the addition of new items.The basic process for submitting items to the system for inclusion inthe running total of a buyer's inventory is captured in FIG. 3. A DataCollection Device 128, 130, 132, 136, 138, 140 submits a product codefor comparison to values in a Product Information Database 200. Usinglogic in the Data Subset Presentation Engine 206 (described in greaterdetail below), the system increments the total quantity record for theidentified product in the Central Inventory Data Repository 104, forlater viewing by authorized system participants via a CommunicationsInterface for Formatting/Viewing Data 142, 144, 146, 148,150, 152, usingpresentation logic residing in the Data Subset Presentation Engine 206.

[0079] 1.2. Identification of products based on full or partialuser-provided input. Users increment their inventory records by firstidentifying the code of the product they wish to add. For the preferredembodiment of this invention, that code is expressed in barcoded format,read by a Data Collection Device 128, 130, 132, 136, 138, 140, forexample, a barcode scanner. Two problems work against the accuracy andclarity of the records for the parties sharing the data through thissystem. First, the codes may be expressed or read inconsistently, evenfor the same product. “H123” and “+H123−” may represent one product, and“H123A” and “H123B” may represent different unit containers of oneproduct (e.g., 1 in the box for “H123A” and 10 in a case for “H123B”),but storing the different values on behalf of that product in theCentral Inventory Data Repository 104 would misrepresent the totalquantity, making effective management of inventory impossible. Forexample, a perceived quantity of “0” of product “H123” may simplyreflect the data collection device's preference for passing “+H123−” asthat product's identifying code to the Product Information Database 200.The invention protects against this confusion with the measuresdescribed below in this section.

[0080] 1.2.1. Exact match of the user's initial input. The ProductInformation Database 200 stores values for each unit size of eachproduct within a given marketplace. If the initial code from the DataCollection Device 128, 130, 132, 136, 138, 140 is an exact match of aproduct ID code in the database, this value is used to update theCentral Inventory Data Repository 104, including the incrementing oftotal quantity of that item.

[0081] 1.2.2. Parsing of the code from the Data Collection Device 128,130, 132, 136, 138, 140. If no exact match is found for the initialcode, the current embodiment of the invention attempts a series ofmodifications to that code in a bid to find an exact match with someelement of a product record in the Product Information Database 200. Forexample, the current embodiment of the invention systematically removescharacters from the beginning and end of a user-submitted code, such as“+H123−,” eventually finding a match with “H123.” The eliminatesvariation in the identification of the item coded “H123.”

[0082] 1.2.3. Multiple matches. Though the Product Information Database200 enforces uniqueness in product ID codes, the parsing described abovemay yield multiple matches with records in the Product InformationDatabase 200. If multiple matches are found, the Data SubsetPresentation Engine 206 checks the records from the Product InformationDatabase 200 for identical manufacturer and other item identification,indicating a single product type with different packaging sizes. In thiscase, the Data Subset Presentation Engine 206 favors the lowestavailable quantity; it offers the alternatives only when necessary forproper tracking of the lowest tracked unit size (e.g., in the case ofmanagement by case, carton, or multiple-item container). In the absenceof a positive determination of a single product with multiple packsizes, the Data Subset Presentation Engine 206 returns all possibleoptions, enabling the user to choose.

[0083] 1.2.4. Automatic determination of product identificationrequirements. From a comparison of the user-provided product code to aseries of user-established preferences for inventory handling (in thisembodiment, covering issues such as whether lot number are required foradding a certain product to inventory or the status of the product forconsignment purposes), the Data Subset Presentation Engine 206 canselectively request more input from users, to increase the detail of theuser's portion of the Central Inventory Data Repository 104.

[0084] 1.2.5. Storage and modification of mutually visible parameters. Abuyer's establishment and upkeep of its portion of the Central InventoryData Repository 104 creates the shared content at the core of thisinvention. Examples include product identification numbers, lot numbers,expiration dates, storage locations, quantities, etc.

[0085] 1.2.6. Automatic identification of parameters based on analysisof product coding (e.g., determination of expiration date, point oforigin, date of manufacturer, etc. from lot number or serial numberbarcode). The invention incorporates logic in the Data SubsetPresentation Engine 206 to derive from various user-provided data otherimportant product parameters. An embodiment of this logic is thefollowing algorithm excerpt: if len(strUPN_unaltered)= 22 then     ifmid(strUPN_unaltered,15,2)=“10” then   lot number delimeter     strLot =mid(strUPN_unaltered,17)     strLot = Replace(strLot, “<”, “&lt;”)    strLot = Replace(strLot, “>”, “&gt;”) end if

[0086] This says, if the length of the user's input is 22 characters,and the number “10” occurs in the 15^(th) position in the input, thenthe following characters is a lot number.

[0087] 1.2.7. Adding an item to inventory in this invention triggerscertain routines to determine if additional user interaction is requiredto initiate some other process within the system. For instance:

[0088] If an item is being added to a buyer's inventory for the firsttime, the buyer is given the option of adding details such as the price,par level, internal code, and the necessity for indicating lot numberand expiration data on future additions of like products.

[0089] If the item is “consigned” to the buyer by the seller, the DataSubset Presentation Engine 206 can note this fact in the Central

[0090] Inventory Data Repository 104, to trigger functions by the DataSubset Presentation Engine 206 and change the parameters of display toother system participants through their Communications Interface forFormatting and Viewing Data 142, 144, 146, 148, 150, 152. For example,“consigned” status may move a product to a separate Alert or Viewingfunction for the supplier of the consigned item.

[0091] 1.3. Exception handling for product identification. If theuser-submitted code is not identified by any effort of the Data SubsetPresentation Engine 206.

[0092] 1.3.1. Initial input not recognized. In this case, the DataSubset Presentation Engine 206 redirects the user to a process thatallows the user to submit additional information manually to the DataSubset Presentation Engine 206 (an example in the preferred embodimentis the selection of the product's manufacturer from a list and manualentry via a Data Collection Device 128, 130, 132, 136,138, 140 of aproduct catalog number).

[0093] 1.4. Reconcile. To ensure the values for parameters such asquantity, lot number, and expiration date in the inventory system areaccurate, the buyer can use the Data Subset Presentation Engine 206 tocompare physical inventory to system inventory. In the Reconcileprocess, the user submits data from Data Collection Device 128, 130,132, 136, 138, 140 to the Product Information Database 200, whichinterprets the data. The Central Inventory Data Repository 104temporarily stores the new data for comparison to existing records inthe Central Inventory Data Repository 104, identifying discrepanciesbetween the physical and virtual inventories and allowing the user tocorrect those discrepancies through the Data Subset Presentation Engine206.

[0094] 1.4.1. Reconcile Order. The contents of incoming shipments, forwhich order documents were prepared previously using the Data SubsetPresentation Engine 206 in tandem with the Central Inventory DataRepository 104, may be reconciled against the expected contents of theorder. The addition of products to a current inventory record is subjectto all steps in the product identification process described above.

[0095] 1.5. Acknowledge Order. One-step process that enables a recipientto add to inventory records all products associated with a single ordernumber, simply by acknowledging receipt of a shipment corresponding tothat number. Addition of products to a current inventory record issubject to all steps in the product identification process describedabove.

[0096] 2. Monitor. Features of the Data Subset Presentation Engine 206,accessed by the Communications Interfaces for Viewing and TransmittingData 142, 144, 146, 148, 150, 152. View. The buyer's view of detailedinventory data is limited to its own inventory. Buyers may use theinvention to create links between their inventories, for sharedvisibility. In no case can any unauthorized buyer view another buyersinventory.

[0097] 2.1.1. View Customization—format variations. The invention offersthe user certain controls for changing the way data is viewed. Examplesinclude selecting between two-dimensional data tables and vertical,hierarchical data trees (FIGS. 6 and 7—images created from screens of acurrent embodiment of the invention).

[0098] 2.1.2. View Customization—content variations. The inventionallows users to manipulate the data sets to which they have access, byaltering the order, number and type of data fields requested from theData Subset Presentation Engine 206.

[0099] 2.2. Par Level Creation and Modification. A Buyer's par levelsrepresent ideal stocking levels. At the par level, supply is neither toolow, creating a risk of shortages, nor excessive, representing a strainon capital and storage resources.

[0100] 2.3. Alerts. The Data Subset Presentation Engine 206, acting oncontinuous comparisons between various values in the Central InventoryData Repository 104 and user-determined thresholds for differences inthose values, automatically sorts alerts, or messages for immediate userattention, into the following types (FIG. 8):

[0101] 2.3.1. Highlights. Summaries of the other Alerts groupings—totalnumbers of various types of Alerts.

[0102] 2.3.2. Low Stock 410. Where current quantity<or=par level−(parlevel×user's low stock threshold percentage).

[0103] 2.3.3. Overstock 420. Where current quantity>or=par level+(parlevel×user's overstock threshold percentage).

[0104] 2.3.4. Expired. Where expiration date<today's date.

[0105] 2.3.5. Nearing Expiration. Where expiration date−user'sexpiration date threshold expressed in months<today's date.

[0106] 2.3.6. Watch Lists. The relationship between these Alerts ensuresthat no product is “invisible” to the users on either end of thetransaction during the time that it remains “on order,” prior to itsreceipt (see FIG. 8).

[0107] 2.3.6.1. Low Stock Watch List 430. Where quantity<=par level−(lowstock threshold×par level) AND quantity+quantity on order>=parlevel−(low stock threshold×par level) AND quantity+quantity onorder<=par level+(over stock threshold×par level)

[0108] 2.3.6.2. Overstock Watch List 440. Where quantity<=parlevel+(over stock threshold×par level) AND quantity+quantity onorder>=par level+(over stock threshold×par level)

[0109] 2.3.6.3. Products on Order 450. Where quantity>par level−(lowstock threshold×par level) AND quantity+quantity on order<parlevel+(over stock threshold×par level) AND quantity on order>0

[0110] 2.3.7. Consigned Product Used. Alerts Buyers to the usage of aconsigned product (one do not yet own but which has been placed withthem for use or sale by the supplier, in anticipation that the use orsale of that item will trigger purchase of the item by the buyer fromthe supplier).

[0111] 2.4. Search. Subject to the limits established by theirindividual identities, users may search the Central Inventory DataRepository 104 and Product Information Database 200 using theirCommunications Interfaces for Viewing and Transmitting Data 142, 144,146, 148, 150, 152. The Data Subset Presentation Engine 206 interpretsand allows manipulation of the results.

[0112] 2.5. Reports. Reports use the Data Subset Presentation Engine 206to present a view of a data subset to an authorized user.

[0113] 2.5.1. Parameters initially set. Reports with parametersinitially set do not require the user to interact with software controlin the Data Subset Presentation Engine 206 to see an initial result(this result may be customized subsequently).

[0114] 2.5.2. Parameters set by user through interaction with software.Reports with parameters set by user through interaction with softwaredirect the Data Subset Presentation Engine 206 as to which particulardata points the user wishes to see.

[0115] 2.5.3. Memorized. Any data set presented by the Data SubsetPresentation Engine 206 may be saved or “memorized” by the user, forlater retrieval.

[0116] 2.6. Hosting of User-Provided Data. This invention relies in manyparticulars on sharing a single body of information between multiplebuyers and multiple sellers over a common communication platform.However, the preferred embodiment also provides a structure andelectronic storage for the internally meaningful data—codes, prices,names, etc.—of participants in the system. The user identity andsecurity key protections ensure that this information is not shared withunauthorized user, though participating organizations may elect toreveal certain data points to certain of their buyers or suppliers.

[0117] 3. Record Usage/Sale

[0118] 3.1. Removal. A Data Collection Device 128,130,132,136,138,140passes a code number to the Product Information Database 200 foridentification. The identified code is used by the logic in the DataSubset Presentation Engine 206 to decrement the appropriate record inthe Central Inventory Data Repository 104. Product identification fromthe user-provided code relies on processes described in Sections 1.2 and1.3 above in the Buyer's cycle.

[0119] 3.2. Detailed Usage/Sale Records (an embodiment is the presentinvention's Encounters feature). In addition to submitting codes ofproducts to be removed from the running total of items in inventory, theDetailed Usage/Sale Records component enables the buyers, prompted bylogic in the Data Subset Presentation Engine 206 pertaining to use orsale of the products (to whom it was sold, under what conditions, atwhat discount, with what outcomes, etc.) to use a CommunicationsInterface for Formatting and Viewing Data 142, 144, 146, 148, 150, 152to supplement the record of the removal in the Central Inventory DataRepository 104.

[0120] 3.2.1. Archive of usage records. The invention provides aninformation storage platform (preferred embodiment: the CentralInventory Data Repository 104) for subsequent retrieval of a buyer'susage records.

[0121] 3.3. Consigned product usage and notification. The inventionprovides tools within the Data Subset Presentation Engine 206 for abuyer to notify a seller about use of and need of replacement forconsigned goods through a Communications Interface for Formatting andViewing Data 142, 144,146,148, 150, 152, along with access controls fortransferring transaction details to the intended party (appropriatesupplier), exclusive of other suppliers.

[0122] 4. Order

[0123] 4.1. Automated from Alerts section. The Low Stock Alert describedin Section 2.3.2 allows the buyer to use a Communications Interface forFormatting and Viewing Data 142, 144, 146, 148, 150, 152, along withfunctions contained in the Data Subset Presentation Engine 206, tocreate orders for entry into other, unrelated systems or for directtransmission, via the Data Subset Presentation Engine 206, to suppliers.In the preferred embodiment, the user selects “order” across from anyline item indicated to be in short supply, then selects a “prepare orderworksheet” button to retrieve a record from the Central Inventory DataRepository 104 via the Web browser, detailing the number of products tobe ordered (the difference between the user's par level and the currentquantity, changeable by the user). Once completed, this order worksheetupdates the Central Inventory Data Repository 104 to note that theproduct is on order. In the preferred embodiment, this status is alteredeither by the user's adding of this product to his inventory record orby the Reconcile Order or Acknowledge Order function contained in theData Subset Presentation Engine 206.

[0124] 4.2. Manual. A manual order combines logic for searching theProduct Information Database 200, storing details in the CentralInventory Data Repository 104, and communicating those details in theform of an order worksheet to any authorized participants in the systemvia a Communications Interface for Formatting and Viewing Data 142, 144,146, 148,150, 152.

[0125] 4.3. Standing-order management. Standing orders use details fromthe Central Inventory Data Repository 104 and order-creation logic fromthe Data Subset Presentation Engine 206 to prepare repeating, identical(but editable) order worksheets for products presumed to needreplenishment in like amounts at regular intervals.

[0126] 4.4. Archive of order data. Order data is retained for laterretrieval in the Central Inventory Data Repository 104. The logic forfinding and formatting stored order data is housed in the Data SubsetPresentation Engine.

[0127] Supplier's Product Management Support Cycle: Monitor. Insupporting its customers using this invention—performing such tasks ashelping a customer avoid shortages, product spoilage, overstocking,uneven stocking levels of key products, etc.—the supplier uses aCommunications Interface for Viewing and Transmitting Data 142, 144,146, 148, 150, 152 to access data from the buyer's portion of theCentral Inventory Data Repository 104. The tools used in this supportrole, launched from the Data Subset Presentation Engine 206, functionidentically to those used by buyers. The difference is the range of dataavailable to a supplier.

[0128] 1. Monitor

[0129] 1.1. View. The supplier's access to a broad yet tightlycontrolled set of buyer data is at the heart of this invention. Thesupplier sees on his own product at his buyers' location, in real-time,by virtue of a relationship between supplier representatives and buyers,and with the permission of the buyer (granted through selections madethrough an Internet browser (in the preferred embodiment) in functionsstored in the Data Subset Presentation Engine 206, driving modificationsin the Central Inventory Data Repository 104).

[0130] Under no circumstances can one supplier ever view the data oractivity of another supplier. The identity and security keys dictate theterms of access through the user's session.

[0131] 1.1.1. View Customizations—format and content variations.Suppliers have access to controls for two-dimensional data tables,vertical, hierarchical data trees (FIGS. 6 and 7—images created fromscreens of a current embodiment of the invention), and otheralternatives for customizing their view of permitted data.

[0132] 1.2. Alerts. As in Section 2.3 above in the Buyer's ProductManagement Cycle, but limited to notices about inventory conditionsrelative to the supplier's own product lines only. This and all otherreplication of buyer functionality on the supplier side of the inventionis accomplished in this embodiment by separate code in the Data SubsetPresentation Engine 206 for the supplier. This code performs at leasttwo security checks and formats data from the Central Inventory DataRepository 104 accordingly: it determines the user type of therequestor, and upon determining a user type of “supplier,” determineswith which supplier the user is affiliated. Only data pertaining to thissupplier is available to the user he can never see data on anothersupplier's product, from generic parameters such as descriptions orcatalog numbers to specifics such as current quantities, sales dates,prices, expiration dates of stocked product, etc.

[0133] 1.3. Search. Limited as above by the user's code to datapertaining to his or her organization. In the preferred embodiment(using a Microsoft SQL Server database and the ASP coding language forInternet applications), the dynamic inclusion of a “where” clause (e.g.,where manufacturerID=5), drawn from the user's identity, in any databaserequests performed on the Central Inventory Data Repository 104 by theData Subset Presentation Engine 206, limits search results to a user'sown organization, while providing real-time visibility into buyerinventory levels and other data.

[0134] 1.4. Reports. Functions as in 2.5 above for the Buyer's ProductManagement Cycle, with available data limited by the user's identity andsupplier affiliation.

[0135] Supplier's Internal (Field-Based) Product Management Cycle:Receive, Monitor, Use/Distribute, Order. These features of one preferredembodiment of the system (an inventory system between multiple buyersand multiple sellers of implantable medical devices) pertain tomaintenance of a field-based inventory of products by a supplier's salesor service forces. Sometimes called “trunk stock,” this inventory isused for product demonstration or as a limited, widely disperseddistribution channel to satisfy urgent buyer needs.

[0136] 1. Receive

[0137] 1.1. Add. As in Section 1.1 above in the Buyer's ProductManagement Cycle, but access is limited to the supplier's own productlines. Constrained by a “where” clause that dynamically inserts thesupplier-user's supplier (employer) code, the supplier may not call fromthe Product Information Database 200 or store in the Central InventoryData Repository 104 any data pertaining to other manufacturer'sproducts.

[0138] 1.1.1. Identification of products based on full or partialuser-provided input, handling of multiple product code matches andunidentified products codes (exceptions). As in Section 1.2 above in theBuyer's Product Management Cycle, with access limited to the supplier'sown product lines.

[0139] 1.1.2. Storage of and access to dynamic product parameters fromthe Central Inventory Data Repository 104 (e.g., quantities, lot numbersexpiration dates, par levels, etc.). A supplier may, at its discretion,give its customers visibility into its field-based inventory, usingconstraints set by the supplier in the Data Subset Presentation Engine206 (for example, giving customers in the Northeastern U.S. accessthrough a Communications Interface for Formatting and Viewing Data 142,144, 146, 148, 150, 152 for reviewing available inventory of sales andservice representatives covering that territory).

[0140] 1.2. Reconcile. As in Section 1.4 above in the Buyer's ProductManagement Cycle, with access limited to the supplier's own productlines.

[0141] 1.3. Acknowledge Order. As in Section 1.5 above in the Buyer'sProduct Management Cycle, with access limited to the supplier's ownproduct lines.

[0142] 2. Monitor

[0143] 2.1. View. As in Section 2.1 above in the Buyer's ProductManagement Cycle, with access limited to the supplier's own productlines.

[0144] 2.2. Alerts. As in Section 2.3 above in the Buyer's ProductManagement Cycle, with access limited to the supplier's own productlines and, in one embodiment, the following supplier-specific Alerttypes.

[0145] 2.2.1. To Be Returned—Loan/Trade/Exchanged from Customer.Provides a section in the Alerts function of the Data SubsetPresentation Engine 206 that retains a record of any product “added” toa supplier's field-based inventory and recorded in the supplier'sportion of the Central Inventory Data Repository 104 that must later bereplaced for the buyer from whom the product was obtained. The alert issatisfied and disappears when the product is returned to the customer,an event captured during the subsequent removal of a product from thesupplier representative's field-based inventory.

[0146] 2.2.2. To Be Received—Bartered/Loaned to Customer. Provides asection in the Alerts function of the Data Subset Presentation Engine206 that retains a record of any product “removed” from a supplier'sfield-based inventory and recorded in the supplier's portion of theCentral Inventory Data Repository 104 that must later be recovered fromor replaced by the buyer who received the product. The alert issatisfied and disappears when the product is retrieved from thecustomer, an event captured during the subsequent addition of a productto the supplier representative's field-based inventory.

[0147] 2.3. Search. As in Section 2.4 above in the Buyer's ProductManagement Cycle, with access limited to the supplier's own productlines.

[0148] 2.4. Reports. As in Section 2.5 above in the Buyer's ProductManagement Cycle, with access limited to the supplier's own productlines.

[0149] 3. Record Usage/Sale

[0150] 3.1. Removal. As in Section 3.1 above in the Buyer's ProductManagement Cycle, with access limited to the supplier's own productlines.

[0151] 3.2. Detailed Usage/Sale Records (an embodiment is the presentinvention's Sales Disposition feature). As in Section 3.2 above in theBuyer's Product Management Cycle, with access limited to the supplier'sown product lines.

[0152] 4. Order

[0153] 4.1. Automated from Alerts section. As in Section 4.1 above inthe Buyer's Product Management Cycle, with access limited to thesupplier's own product lines.

[0154] 4.2. Manual. As in Section 4.2 above in the Buyer's ProductManagement Cycle, with access limited to the suppliers own productlines.

[0155] 4.3. Standing order management. As in Section 4.3 above in theBuyer's Product Management Cycle, with access limited to the supplier'sown product lines.

[0156] 4.4. Archive of order data. As in Section 4.4 above in theBuyer's Product Management Cycle, with access limited to the supplier'sown product lines.

[0157] Intermediary's (Coordinator's) Management Cycle: Setup, Review,Resolve. The system coordinator maintains a series of controls over datarelationships between the participating buyers and sellers, maintainsthe accuracy and integrity of data in the Product Information Database200 and Central Inventory Data Repository 104, and assigns and securesthe identities, roles, and permissions of system users, which are storedin the Central Inventory Data Repository 104.

[0158] 1. Setup.

[0159] 1.1. Creating links for shared visibility. Certain logic in theData Subset Presentation Engine 206 relies on coded relationshipsbetween parties to determine access to information. One example in thepresent embodiment may be access by a user within one department of anorganization to the data records regarding inventory or personnel ofanother department in the same organization. Another might be real-timeaccess, via a Communications Interface for Formatting and Viewing Data142, 144, 146, 148, 150, 152, to buyer inventory data in the CentralInventory Data Repository 104 for the representative of a supplier tothat buyer. A preferred embodiment of security for these restrictions isthe access security described above in the Security and Access Controlsection, in addition to a system for encryption (Secure Socket Layer isan embodiment) of data traveling across a common communications system(e.g., the Internet).

[0160] 2. Review. A preferred embodiment of the invention provides adedicated interface for the coordinating party or intermediary, withlogic and controls residing in the Data Subset Presentation Engine 206.The interface provides broad access to the Central Inventory DataRepository 104 and Product Information Database 200 for the coordinatorand its representatives, subject to password protection and security keychecking.

[0161] In the preferred embodiment, these passwords are encrypted so asnot to be human readable, and therefore unknown to all users but theirowner.

[0162] 3. Resolve. In addition to simple “viewing” access, the preferredembodiment of this invention provides tools within the Data SubsetPresentation Engine 206 for the coordinator's representatives to resolvedata issues and maintain and modify both the Central Inventory DataRepository 104 and the Product Information Database 200. These issuesincludes but are not limited to correcting erroneous product data,clearing passwords, altering database structure in the ProductInformation Database 200 or logical structure in the Data SubsetPresentation Engine 206, and modifying links between participants in thesystem, which are then stored in the Central Inventory Data Repository104 to be referenced by logic residing in the Data Subset PresentationEngine 206.

[0163] It should be appreciated that the embodiments described above areto be considered in all respects only illustrative and not restrictive.The scope of the invention is indicated by the following claims ratherthan by the foregoing description. All changes that come within themeaning and range of equivalents are to be embraced within their scope.

We claim:
 1. A method for transferring information between multiplebuyers and multiple vendors, comprising: receiving informationcorresponding to a plurality of products from a plurality of sources;storing the information in a first database; receiving a request for aportion of the information stored in the first database; retrieving theportion of the information corresponding to the request from the firstdatabase; posting the information on a second database, the informationcorresponding to the request; and providing access to subsets of thesecond database to a plurality of subscribers.
 2. The method of claim 1,further comprising providing access between at least one of theplurality of subscribers and at least one of the plurality of sources.3. An inventory management system, comprising: a central node; aplurality of vendors electronically coupled to the central node; aplurality of buyers electronically coupled to the central; and first andsecond databases electronically coupled to the central node; wherein arequest from one of the plurality of buyers is received as the centralnode which obtains information stored on the first database from atleast one of the plurality of vendors and displays the information onthe second database.